Reliable transport protocols operating on top of IP, such as Streaming Control Transmission Protocol (SCTP), are often used by network components (e.g., clients, etc.) communicating with application servers via Application Protocol Data Units (APDU) over established connections (e.g., a connection-oriented service such as that provided by SCTP). With such arrangements, network components typically use a host server cluster which may, in part, be based on a requirement for each network component to have several physical resources associated therewith for scalability purposes.
FIG. 1 illustrates SCTP signaling 100 relating to the establishment of an association (for an application data transfer, etc.) between a client 110 (end point EP A) and a server 120 (end point EP Z). Several transport addresses are associated with the client 100 (i.e., it is a multi-homed end point) comprising pairs of valid IP addresses for the client and the port number chosen for the client (which is typically only valid for the lifetime of the SCTP association). The IP addresses are given as the list {IP A1, . . . , IP An} and the port number is indicated as P A.
Similarly, there are transport addresses for the server 120, that are pairs created from the IP addresses of the list {IP Z1, . . . , IP Zm} and the port number P Z. Often, the port number for the server 120 is a well-known port defined for a particular application on top of SCTP (e.g., port number 2905 as defined in the protocol for MTP3 User Adaption Layer (M3UA)). In any event, the port number and the IP addresses associated with the server 120 (and/or the corresponding application) must be known by all clients 110.
The process for establishing an association commences with the client 110 sending an initiation request (e.g., an INIT packet in the case of SCTP) 130 to the server 120 via one of the valid IP addresses for the server 120 and the server port number. The request 130 will include a list of IP addresses and the port number valid for the client 110, indicated as the IP address list and the port number. An example request 130 might contain the following: destination IP address=IP Zy; source IP address=IP Ax; (source port=P A; destination port=P Z; chunk=INIT; end point IP addresses={IP A1, . . . , IP An}). While the destination IP address and the source IP address are usually included in the IP packet header, the remaining parameters in brackets are sent as SCTP packet header that is included in the IP packet payload.
In response, the server 120 will reply with an acknowledgment (e.g., an INIT ACK message in the case of SCTP) 140 if it accepts the initiation request 130. The acknowledgment 140 is directed to the same address from which the request 130 was received, but it may be sent by the server 120 from a different address than the one that received the INIT message (e.g., IP address Zz). The acknowledgment 140 will also include data defining the end point of the server 120, such as the valid IP addresses and the same port number as already used as the destination port number in the INIT messages. A sample acknowledgment 130 might include the following: destination IP address=IP Ax; source IP address=IP Zz; (source port=P Z; destination port=P A; chunk=INIT ACK; end point IP addresses={IP Z1, . . . , IP Zm}). After this acknowledgment has been received by the client 110, several more messages may be exchanged (i.e., hand-shaking may take place) for security purposes and so that the various transport addresses are known for each end point to choose among them as may be required to exchange payload data.
The above described conventional manner in which SCTP associations are established is susceptible to denial of service (DoS) attacks as massive number of automated requests to various servers can cripple communication exchanges (by effectively disabling the servers). While it may be possible, in some circumstances, to scale up processing power by adding further servers and building server clusters when traffic demands are high, the various clients must be informed how to best use additional resources. Accordingly, load-balancing cannot be achieved without coordination between all of the various clients. While Domain Name System (DNS) may provide some benefits regarding load sharing, the use of DNS and corresponding domain names can be overly cumbersome for some applications.
In an analogous art, routers, such as Internet routers, are used to determine how data is sent to its intended destination via the most efficient route. In addition, routers are used to segment traffic (by, for example, monitoring the transmission of each data packet) and provide redundancy of routes. While this arrangement can act to ensure that data is transferred to a recipient in an efficient manner, routers are susceptible to overloading during heavy data traffic.
US 2002/0138618 A1 discloses a connection management technique that is implemented using a load balancing server array controller arranged between an internal network and an external network. The controller receives connection requests from the external network, transforms the connection requests and forwards the transformed connection requests to a selected content server. Responsive to the transformed connection request, the content server sends a TCP/IP acknowledgement message to the controller. The controller then transforms the acknowledgement message and forwards the transformed acknowledgment message to the client from which the connection request has originally been received.
Accordingly, it will be appreciated that there remains a need for an improved technique for receiving and acknowledging a high volume of initiation requests that can be modified without significant coordination with a multitude of clients.